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Methods, systems, and computer program products are disclosed for automatically filling in an electronic form on a user computer 
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METHOD AND APPARATUS FOR CLIENT SIDE 
AUTOMATIC ELECTRONIC FORM COMPLETION 

Background of the Invention 

1 . Field of the Invention 

The present invention relates generally to computer software for filling out form 
documents over a computer network. More particularly, the present invention provides a 
method and system for automatically filling out fields in an electronic form document on 
a browser program using a remote server. 

2. Discussion of Related Art 

Rapid growth and technological advances have changed the way most people 
currently use computers. During the early days of computers, a paradigm existed 
whereby there were more computer users than computers, and thus most computers had 
many assigned or dedicated users. As technology progressed, the personal computer 
("PC") emerged, and it became commonplace for many computers to have only one user. 
Subsequent growth, particularly in the 1990s, has seen a culture or paradigm emerge 
whereby a computer user has access to more than one computer. As such, many 
individuals now have substantial access to multiple computers, for example at 
workplaces, schools, libraries, homes, and while traveling. This ratio of available 
computers per computer user should increase even further over time. It is therefore 
increasingly desirable to have computer-based programs and services that are accessible 
to a particular user from any computer, and not just those computers that have been 
programmed or adapted for that particular user. 
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One result of the recent explosion in computer growth is the amount of 
communication that now takes place between separate computers or computer systems. 
Many methods and systems exist for communications between computers or computer 
systems. This is reflected in many contexts, such as in the growth of the Internet. For 
5 purposes of the following discussion, several methods and systems will be described with 
reference to the Internet as a matter of convenience. It should be understood, however, 
that this is not intended to limit the scope of this discussion, and that many other 
applicable devices and protocols for computer communications exist, such as "Intranets", 
closed proxy networks, enterprise-wide networks, direct modem to modem connections, 
10 etc. 

A browser program capable of running; one or more windows may utilize a 
simple process for communicating information among computers over the Internet, as 
illustrated in FIG. 1 . Typically, an independent Internet user 1 06, from a pool of random 
independent Internet users 101-106, opens a browser window 131 in an Intemet browser 

15 program, depicted by arrow 161. User 106 then enters a request for an Intemet Web 
page 144 (i.e. an HTML page) to be downloaded into browser window 131 belonging to 
user 1 06. User 1 06*s request is processed by the browser program, and a cormection, 
depicted by arrow 162, is made with the appropriate remote Intemet resource 112, 
typically an Interne Web server, selected from a pool of random remote Intemet 

20 resources 110-112. Remote Intemet resource 112 retums an HTML document 143, 
depicted by arrow 163. HTML document 143 contains substantially the entire content 
needed to display completed Web page 144. Web page 144 is then displayed back to 
user 106 in browser window 131, depicted by arrow 164. 

A model known in the art as the "ad server" model advances this simple browser 

25 program method for communicating information over the Intemet. Many Intemet Web 
pages are composite pages, requiring information in the form of images, text, and/or code 
to be pulled from several different remote Intemet resources. Ad servers are generally 
used to integrate directed electronic material, such as banner advertisements, into such 
composite Intemet Web pages. Thus, ad servers are one example of a remote Intemet 

30 resource that separately contributes material to a composite Web page. A computer 
network communication process utilizing an ad server is also depicted in FIG. 1. 

Independent Intemet user 102 opens a browser window 130 in his or her Intemet 
browser program, depicted by arrow 151. User 1 02 then enters a request for an Intemet 
Web page 142 to be downloaded into browser window 130. This request is processed by 

35 the browser program, and a cormection, depicted by arrow 152, is made with the 
appropriate remote Intemet resource 110, typically an Intemet Web server. Remote 
Intemet resource 1 10 retums a core HTML document 140, depicted by arrow 153. Core 
document 140 contains some displayable content and an additional link to another 
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image 141, in this case a banner advertisement, stored at a separate remote Internet 
resource 120, in this case an ad server. The browser program parses core document 140 
to find and use this link to retrieve image 141. The browser program then makes a 
connection, depicted by arrow 154, with remote Internet resource 120 to retrieve 
5 image 141. Remote Internet resource 120 returns image 141 to the browser program, 
depicted by arrow 155. Image 141 is then merged with the displayable content of core 
document 140 to comprise completed Web page 142. Web page 142 is then displayed 
back to user 102 in browser window 130, depicted by arrow 156. It should be 
appreciated that this process may be repeated many times for many separate portions of a 

1 0 particular Web page. In fact, many Web pages contain links to dozens of separate remote 
Internet resources, requiring this process to be repeated for each separate link. 

Many remote Internet resources assign a specific user identifier containing state 
information, referred to as a session identifier or "cookie", to each particular user 
whenever a user connects to the resource, for example to retrieve an Internet Web page. 

15 This cookie is deposited into the user's browser program, which is instructed to show the 
cookie to the resource upon subsequent visits so that the resource can identify the user. 
The cookie conveys to the resource who the user is and what document or component 
thereof that the user wants. Use of these cookies is vital when components are assembled 
fi-om various remote Internet resources into one integrated Web page, as a resource for a 

20 core HTML document may require several visits or communications from a Web 
browser while a page is assembled. Without such cookies, use of composite Web pages 
would be substantially hindered. Many resources assign temporary cookies for this 
purpose, which expire at the end of a session or when the browser program is closed. 
Other cookies, however, are £issigned for longer durations for identification purposes 

25 beyond one Internet session. One such purpose identifies users, through long-term or 
persistent cookies, to specific user history and preferences, such that information, for 
example content specific banner advertisements related to such user history and 
preferences, may be directed at identified users in the future. 

Proxy systems generally group many individual computers and computer users 

30 into a single network. This network is typically served by a single proxy server, which 
serves as a conduit for all communications among individual network users and between 
any individual network user and any outside remote electronic resource or user. A proxy 
server may provide several usefiil functions, such as faster communication between 
network users, firewall protection for all network computers, and large and efficient 

35 storage. One example of efficient storage by a proxy server occurs when one network 
user requests a Web page from a remote resource that has recently been retrieved by 
another network user. Rather than retrieve the same Web page from the same remote 
resource again, the proxy server may simply deliver the Web page that has been stored 



SUBSTITUTE SHEET (RULE 26) 



wo 00/42540 



-4- 



PCT/USOO/01031 



on it from the previous request. It should be appreciated that while the use of proxy 
servers alters the path through which information and communication may travel, such 
use does not substantially alter the basic functions of the methods and systems described 
herein. 

5 In general, many methods may be used to assist a user in filling out an electronic 

form document. One such method is referred to as the "wallet" method, which may be 
found, for example, at "eWallet" located at http://www.ewallet.com. This method 
requires a user to download a software application and install it onto his or her computer. 
The user is then required to input personal information items into the application, 

10 including the user's name, address, and credit card information, which is stored on the 
user*s computer for future use. The user is then able to use this "eWallet" application and 
inputted personal information items to automatically fill out electronic form documents 
that are affiliated with the "eWallet" application. Whenever the user desires to fill out an 
affiliated electronic form document, the user opens the "eWallet" application and clicks 

15 and drags a virtual credit card from the virtual wallet onto the form document. The 
"eWallet" application then automatically inserts the inputted personal information items 
into the document. The click and drag step must be repeated for each page of the 
electronic form document. The user is then able to review and approve the form 
document before transmitting it as complete. 

20 Another method for assisting a user in filling out an electronic form document is 

referred to as the "transactor" method, which may be found, for example, at "Transactor 
Networks" located at http://www.transactor.net. This method differs from the wallet 
method in that the user is not required to download or install any software onto his or her 
computer. Instead, personal information items are input and stored in a database on a 

25 remote server, which is then accessed every time an electronic form document is to be 
filled. This remote server containing the personal information items is accessed through 
a browser window separate from the browser window containing the electronic form 
document to be filled. This method thus requires communication between separate 
browser windows. 

30 A method for filling; out an electronic form document using this transactor 

method is illustrated in FIG. 2. Independent Internet user 202, from a pool of random 
independent Internet users 201-206, opens a browser window 230 in his or her Internet 
browser program, depicted by arrow 25 1 . User 202 then enters a request for a Web page 
containing an electronic form document 240 to be downloaded into browser window 230. 

35 This request is processed by the browser program, and a connection, depicted by 
arrow 252, is made with the appropriate remote Internet resource 210, typically an 
Internet Web server, selected from a pool of random remote Internet resources 210-212. 
Remote Internet resource 2 1 0 returns an HTML Web page containing electronic form 
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document 240, depicted by arrow 253. This process may include the retrieval of other 
portions of the Web page from separate remote electronic resources, as described above 
in the ad server model. User 202 also opens another separate browser window 231 to 
activate the "transactor" process, typically done through a bookmark. The browser 
5 program then makes a connection, depicted by arrow 255, with transactor server 220 to 
retrieve the user's personal information items 241 . Transactor server 220 returns personal 
information items 241 to the browser program in browser window 231, depicted by 
arrow 256. It should be noted that the process represented by arrows 254 through 256 
may be completed before or after the process represented by arrows 251 through 253. 

10 Once both processes are complete, window 231 initiates communication with 
window 230 to begin the automated fill of electronic form document 240 in window 230. 
The windows communicate as necessary until form 240 is filled, depicted by double 
arrow 257. Filled electronic form document 242 is then displayed back to user 202 in 
browser window 230, depicted by arrow 258. User 202 is then able to review and 

1 5 approve filled electronic form document 242 before transmitting it as complete. 

There are, however, several drawbacks to both the "wallet" and "transactor" 
methods. Both methods require a substantial initial time investment in requiring a user to 
input all of his or her personal information items. In addition, the wallet method requires 
the user to download and install software to his or her computer. This is problematic in 

20 that the user has no access to this method when he or she uses any computer that does not 
have the wallet program installed and the user's personal information items inputted. It is 
not only inconvenient to re-install and re-input items on every computer for which the 
user has access, but it is practically impossible for a computer being used by a user for 
the first time to have the user's personal information items. While the transactor method 

25 attempts to overcome this deficiency of the wallet method through server-side databases, 
it requires cross-communication between windows, which is known in the art to 
compromise user security. In addition, the requirement of retrieving information from a 
server-side database during window cross-communication significantly slows down the 
automated electronic form document fill process. 

30 As such, what is desired is a method and system for remote server-based 

applications to quickly and automatically fill out electronic form documents, thereby 
relieving the user of the burden of manually inputting data into such form documents and 
without requiring the user to be on any specific computer and without compromising user 
security. In other words, what is desired is a method and system which enables a 

35 computer user to automatically fill out electronic form documents from any computer or 
client location in a network at the simple click of a mouse. Also desirable and inherent in 
such a method and system is the ability to automatically fill out electronic form 
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documents without requiring the user to download or install any type of permanent or 
resident software on any computer. 

Summary of the Invention 
According to the present invention, methods, systems, and computer program 
5 products are disclosed for automatically filling in an electronic form on a user computer 
having a program capable of performing as a browser. The present invention alleviates 
the problem of burdening the user with manually inputting data into an electronic form 
without requiring the user to have any programs or data stored on a user's computer and 
without compromising the user's security by having window cross-communication. This 

1 0 is done through the use of a remote personal information server that registers and stores 
user data and then delivers this user data in an executable code module to any browser 
where the user may be located. 

In one aspect, the present invention provides a method for automatically filling in 
an electronic form document. This method utilizes a browser to access the electronic 

15 form, execute a link to a personal information server, receive a personal information 
module transmitted from the personal information server, and execute the personal 
information module to fill in fields in the electronic form with data contained in the 
module. Advantageously, this permits the user to automatically fill in the electronic form 
without requiring any program or data to be stored on the user's computer and without 

20 using window to window communication. 

In one embodiment, the electronic form is downloaded from a remote Web server 
that has already registered the form with the personal information server. Connections 
between the remote Web server, the user computer, and the personal information server 
are all made via the Internet. In another embodiment, execution of the link includes 

25 transmitting a session identifier, for example a user cookie, and an electronic form 
identifier, for example a Uniform Resource Locator, from the browser to the personal 
information server. In still another embodiment, transmitting the personal information 
module includes examining negotiation history modules derived for the electronic form 
and the user. These negotiation history modules preferably include a form mapping 

30 corresponding to the electronic form and a raw data profile corresponding to the user. 
Another embodiment includes transmitting the electronic form after some or all of the 
fields have been filled in. This transmission may send the filled in electronic form to the 
personal information server, where the user data could be updated as necessary, and also 
to the remote Web server from which the electronic form originated, 

35 In a second aspect, the present invention provides a system for automatically 

filling in an electronic form. This system includes an information server with personal 
information for multiple registered users and form mappings, a Web server with an 
electronic form registered with the information server and having an input button, and a 
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user computer having a browser that can download the electronic form and a user that is 
registered with the information server. The information server and user computer 
communicate over a network to transmit the electronic form, which is then partially or 
completely filled in when the input button is activated. 
5 In a third aspect, the present invention provides for a computer program product 

for automatically filling in an electronic form on a user computer having a browser. This 
computer program product contains a computer readable medium which stores computer 
codes for performing various functions. These functions include accessing the electronic 
form, executing a link to a personal information server, transmitting a personal 
10 information module from the personal information server to the user computer, and 
executing the personal information module at the user computer to fill in multiple fields 
in the electronic form. 

Brief Description of the Drawings 
The invention will be better understood by reference to the following description 
1 5 taken in conjunction with the accompanying drawings in which: 

FIGURE 1 is a diagrammatical representation of an "ad server" model in 
accordance with the prior art. 

FIG. 2 is a diagranmiatical representation of a transactor model in accordance 
with the prior art. 

20 FIG. 3A is a diagrammatical representation of a system for automatically filling 

in electronic form documents in accordance v/ith one embodiment of the present 
invention. 

FIG. 3B is a block diagram showing components of a server enabling the 
automatic insertion of data in to an electronic form on a remote computer in accordance 
25 with one embodiment of the present invention. 

FIG. 4 is a flow diagram of a process for automatically filling in an electronic 
form document in accordance with one embodiment of the present invention. 

FIG. 5 is a flow diagram of a process for an initial user session using the service 
for automatic electronic form completion in accordance with one embodiment of the 
30 present invention. 

FIG. 6 is a flow diagram of a process for constructing and transmitting a 
shippable code segment from a server to a user computer in accordance with one 
embodiment of the present invention. 

FIG. 7 is a flow diagram of a process for mapping through which form names are 
35 mapped to a user's raw data values in accordance with one embodiment of the present 
invention. 

FIGS. 8 A, 8B, and 8C are table diagrams showing the field names and format of 
registered user data in accordance with one embodiment of the present invention. 
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FIG. 9 is a block diagram of a typical computer system suitable for implementing 
an embodiment of the present invention. 

Detailed Description 
Reference will now be made in detail to a preferred embodiment of the invention. 
5 An example of the preferred embodiment is illustrated in the accompanying drawings. 
While the invention will be described in conjunction with a preferred embodiment, it will 
be understood that it is not intended to limit the invention to one preferred embodiment. 
To the contrary, it is intended to cover alternatives, modifications, and equivalents as 
may be included within the spirit and scope of the invention as defined by the appended 
10 claims. 

A method and system for automatically filling; in electronic forms on a computer 
and not requiring a user to download or install any resident software on the computer is 
described in the various figures. As the presence of merchants and services increases on 
the Internet, electronic commerce or e-commerce will grow. More and more consumers 

15 will resort to the Internet, for example, to purchase goods and services. This will 
typically require the consumer/user to provide at least some data to the merchant 
typically through filling out an electronic form having various fields, most commonly 
names, addresses, credit card numbers, phone numbers, etc. For consumers purchasing 
goods from numerous merchant sites and possibly using different computers (e.g. using 

20 a computer at work, using another computer at home, and yet another one while 
travelling), manually filling in these forms repeatedly can become tedious and inefficient. 
The present invention seeks to alleviate the burden of filling in electronic forms, while 
informing the consumer/user of privacy precautions taken by a particular merchant site, 
and not require the user to download any resident software. Inherent in the latter feature 

25 is allowing the consumer to use the processes of the present invention from any computer 
connected to the network, the Internet in particular. 

The present invention uses a remote server or "privacy bank," a novel electronic 
resource that responds to requests for data by preparing and transmitting a specialized 
document in the form of a JavaScript. This JavaScript is formed dynamically by the 

30 privacy bank upon receipt of the request for data. The JavaScript created by the privacy 
bank is a "profile" or mapping between field names in a particular form the user needs to 
fill in at a particular merchant site (e.g. "www.fishermanstore.com") and standardized 
field names stored in the privacy bank server. Once the user's browser program is served 
this profile from privacy bank, most of the fields in the fishermanstore form are 

35 automatically filled in. In the described embodiment, the user becomes a member of the 
privacy bank resource by providing personal information, also referred to as the raw data, 
to privacy bank once. This raw data can be updated from time to time by the user if 
desiired. In another embodiment, the user can enter privacy rules or requirements once 
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when initially becoming a member. The user does not need to download any software 
from privacy bank or any other resource. In the described embodiment, the merchant 
(e.g. The Fisherman Store) becomes an affiliate member of the privacy bank network by 
providing a sample document of its form or forms. Privacy bank can then build a 
5 mapping between fields in the merchant's form and the standardized fields in its own 
database. These processes, components, and related data constructs are described in the 
various figures below. 

FIG. 3A is a block diagram of a system for automatically filling out electronic 
form documents in accordance with one embodiment of the present invention. A number 

10 of end-user computers are shown on the right side of the diagram. These computers can 
be client computers in a network with access to the Internet or be part of an intranet. In 
the described embodiment an end user computer 302 is a stand alone computer with 
access to the Internet and contains an Internet browser program, a browser window for 
which is shown at 304. In the center of the diagram is a number of Web servers. A 

15 particular Web server 306 is a server for a merchant Web site, such as 
www. fishermanstore .com to which users or consumers can visit to purchase goods online 
over the Internet. On the left side of the diagram is a specialized electronic resource 
referred to in the described embodiment as a privacy bank server computer 308, also 
connected to the Internet. 

20 The process of automatic electronic form completion begins with a user 

downloading the form from a Web site such as fishermanstore site. A process of a user 
becoming a member and logging into the privacy bank server is described in greater 
detail in FIG. 5. Returning to FIG. 3A, a user/consumer on computer 302 ("user 302") 
opens a browser window 304 in an Intemet browser program such as Netscape Navigator 

25 or Intemet Explorer, depicted by arrow 310. User 302 then goes to 
www.fishermanstore.com shown by arrow 312 via the browser and decides to purchase 
goods. User 302 then dovmloads from the Web site contained on Web server 306 an 
electronic purchasing form that needs to be completed as depicted by arrow 314. A 
purchasing form 316, typically an HTML document, is returned and downloaded into and 

30 displayed in browser window 304. At this juncture, user 302 would normally have to 
"manually" fill in each field in purchasing form 316. Much of this information is 
typically standard: name, address, phone number, payment method, user email address, 
etc. In accordance with one embodiment of the present invention, user 302 can "click" 
on a privacy bank icon or button in form 316 and have the form automatically filled in. 

35 As stated earlier, it is assumed in thus discussion that v^avw.fishermanstorc.com is 

registered with and thus an affiliate member of the privacy bank service assessable from 
privacy bank server 308. Being an affiliate member of the privacy bank service, 
purchasing form 316 contains a privacy bank icon or button 318. By clicking on privacy 
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bank icon 318, user 302 essentially completes a process for automatically filling in 
form 316 by transparently transmitting a completed form to the privacy bank service on 
server 308, depicted by an arrow 320. The information needed for filling in the form is 
transmitted to user 302 once form 316 (an HTML document) is parsed, which occurs 
5 when form 316 is dovmloaded. This process is described in greater detail in FIG. 4. 
User 302 informs privacy bank server 308 of the identity of the user and of which Web 
site and which form on that Web site (if more than one) the user wishes to have filled in. 
This information is transmitted to privacy bank server 308, unbeknownst to user 302. 
when form 316 is downloaded. Techniques for accomplishing this are described below. 

10 Once privacy bank server 308 receives a request from registered user 302 (by virtue of an 
external link in form 316 executed when the form is parsed by user 302), it begins 
preparing information needed to fill in form 316 on user computer 302. A process of 
preparing the information sent back to user computer 302 and browser 304, depicted by 
arrow 322, is described in greater detail in FIGS. 6 and 7. In the described embodiment, 

15 the information sent to user computer 302 is a JavaScript program 324 referred to as a 
"profile." Explained briefly, this profile contains a mapping of privacy bank standardized 
fields and fields in purchasing form 316 and "raw," generally personal, data associated 
with user 302. The content of this profile and JavaScript program in general is described 
in greater detail in FIGS. 7 A and 7B below. Once received by the browser program on 

20 user computer 302, the filled out purchasing form 316 is displayed to user 302 as 
depicted by arrow 326. This occurs when user 302 presses or clicks on privacy bank 
icon 318. The information needed to complete form 316 is already resident in the 
browser program. At this juncture, user 302 can decide whether to proceed with 
submitting the form (typically after filling out a few more fields such as which items to 

25 purchase, quantity, etc.) or declining to submit the form, perhaps after reviewing the 
fishermanstore*s Web site privacy safeguards or for any other reason. 

FIG. 3B is a block diagram showing components of a privacy bank server 
enabling the automatic filling in of electronic forms on a remote user computer. A 
privacy bank server, such as server 308 in FIG. 3A, contains several ftmctional and 

30 storage components needed for compiling the data needed for filing in a form, such as 
form 316. Shown in FIG. 3B are four major components of a privacy bank server in the 
described embodiment. These components and storage areas include a raw data profile 
storage area 328, a form mapping storage area 330, a negotiation history module 332, and 
a shippable code constructor 334. Raw data profile storage area 328 contains sets of data 

35 relating to registered users of the privacy bank service, one set or profile shown in 
area 336. A registered user has a unique account number that can be used as an identifier 
and a password, shown in an area 338. The standard field names set by the privacy bank 
service, discussed in greater detail in FIGS. 8A, 8B, and 8C, are paired with a user 
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entered data string (such as first name or home street address), followed by a 
use-preference condition. The use-preference condition is used in negotiation history 
module 332 and is discussed in greater detail in FIG. 7 below. This data is contained in 
an area 340. Another profile for another registered user is shown in an area 342. Each 
5 registered user has a similar raw data profile. 

Form mapping area 330 includes multiple form mappings, an example of which is 
shown in an area 344. Each electronic form that is registered with the privacy bank 
service by an online merchant or seller (i.e. an affiliate member) has a form mapping. A 
privacy bank standard field name, as discussed below in FIGS. 8A, 8B, and 8C, and as 

10 mentioned above in area 340, is matched or mapped with a "non-standard" field name 
from the electronic form registered with the service. For ex^ple, a non-standard field 
name for a person's last name could be "Last Name," "Surname" or simply "Last." 
Different forms use different variations of names for this field and for other fields. This 
would be mapped against the privacy bank "standard" field name, which in the described 

15 embodiment, is "PersonName.Last." Also contained in area 346 is a practice-preference 
condition provided by the online merchant or seller when registering the form. As with 
the use-preference condition in area 340, this condition is used by negotiation history 
module 350 and shippable code constructor 334, and is discussed in greater detail below 
in FIG. 7. Another mapping 348 having the same format for another registered form 

20 follows area 344. 

Negotiation history module 332 is used to determine which fields in the electronic 
form will be automatically filled in by the privacy bank server. A process associated 
with negotiation history module 332 is described in greater detail in FIG. 7. Module 332 
includes multiple negotiation objects, an example of which is shown in an area 350. In 

25 the described embodiment, each negotiation object corresponds to one "non-standard" 
field in the form. Described briefly, negotiation object 350 contains information as to 
whether the field in the form should be filled in based on privacy and use preferences set 
by the user (as conveyed in use-preference condition in area 340) and compared to 
intended practices (as conveyed by practice-preference condition in area 346). This 

30 comparison is performed in the negotiation history module, which includes a negotiator 
or comparator for comparing these conditions. Specific conditions in the described 
embodiment are described below. If it is determined that the non-standard field in the 
form will be filled in, a data string, shown in area 340, will be included in negotiation 
object 350. Shippable code constructor 334 accesses component 332 and storage 

35 areas 328 and 330, to derive a software module to be transmitted to a user computer. In 
the described embodiment, the software module is a JavaScript program which is 
transmitted to and executed by a browser in the user computer, thereby inserting the data 
strings into the form fields. 
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FIG. 4 is a flow diagram of a process for automatically filling in electronic forms 
in a computer network in accordance with one embodiment of the present invention. The 
process described below can be performed in a configuration of servers and computers as 
described in FIG. 3A above. At a step 402 an online user/consumer desiring to purchase 
5 certain goods on the Internet downloads an electronic form for making a purchase into 
the user's browser program. At step 404 the browser parses the electronic form content, 
typically an HTML document, to identify all external links. As is commonplace for Web 
pages, the HTML contains links to other external Web sites from which content or other 
types of data is retrieved. In many instances, a Web page is a composite of different 

1 0 components from various sites embedded in a core HTML document. An example is an 
external link to an ad server to retrieve a banner ad component of a core HTML 
document. In this case, the electronic form can be seen as a core HTML document. This 
parsing is done automatically by the browser and is a well known feature. 

At step 406 the browser identifies an external link to the privacy bank server. In 

1 5 the described embodiment, this link will necessarily be present since the Web site is an 
affiliated site of the privacy bank service network of registered sites. A description of 
what "registered" implies in this context is described in greater detail below. At step 408, 
the browser executes the extemad link to connect the browser to the privacy bank server. 
The external link is referred to in the described embodiment as a shippable code link to 

20 the privacy bank server. The shippable code in this context is a JavaScript program that 
is transmitted from the privacy bank server to the user computer and browser. Thus 
shippable code enables the electronic form to be filled in automatically in a process that 
is described in greater detail below. At step 410, once the privacy bank server has been 
contacted via the shippable code link in the electronic form, the privacy bank server 

25 determines whether the user computer or browser has a valid state identifier, referred to 
as a "cookie", previously assigned to it by the privacy bank server. A cookie is an 
identifier assigned by a Web site, whether a Web server or a server such as the privacy 
bank server, to a user/visitor when the user visits the Web site for the first time in a given 
session (the time from which a user logs onto the Web and the time he or she exits the 

30 Web by exiting the browser). The cookie, assigned by a Web site, belongs to a particular 
user. In the described embodiment, the user keeps this cookie during its session (a 
temporary cookie) and if the user goes back to that Web site during that session, it shows 
the Web site that cookie from which the Web site can identify the user and retrieve 
characteristics of that user from its data repository. As is known in the art of Internet 

35 application programming, cookies can also be permanent in that they subsist with a user 
after the user has logged off the browser and can be used again in a new session. The 
concept and implementation of cookies themselves are well known in the field of Internet 
and, more generally, computer network programming. 
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If the privacy bank server determines that the user computer or browser does not 
have a valid cookie, it implies that the user has not yet logged into the privacy bank 
service. If so, control goes to step 412 where the privacy bank server retrieves a login 
sequence code. This code will trigger a login sequence and enable the user to log in to or 
5 register with the privacy bank service at a later step in the process, as described in greater 
detail below. At step 414, the privacy bank server forms a completed package of 
shippable code containing the retrieved login sequence code, such that the login sequence 
will be triggered at a later step in the process. At step 422, the browser retrieves this 
completed package of shippable code from the privacy bank server. The shippable code 

10 is then stored in the browser residing on the user's computer, and is executable upon a 
user trigger, which is described in greater detail below. 

If the privacy bank server determines that the user/browser making contact by 
downloading the electronic form and executing the external link has a valid cookie, 
control goes to step 416 where the privacy bank server gets and reads the user's cookie. 

15 In this context, having a valid cookie indicates that the user has already gone through the 
login sequence recently, for example during the existing Internet session, and thus it is 
not necessary for the user to go through the login sequence again. By reading the user's 
cookie, the privacy bank server can determine who the user is and thus can retrieve the 
user's raw data stored by privacy bank. The contents and format of this raw personal data 

20 is described in greater detail in FIGS. 8 A, 8B, and 8C below. At step 418, the privacy 
bank server retrieves the user data for the user identified by the valid cookie. The 
privacy bank server couples this user data and an identifier, such as a URL (uniform 
resource locator), to determine how the electronic form document should be filled. At 
step 420, the privacy bank server forms a completed package of shippable code (item 324 

25 in FIG. 3A) containing the user data that will be used to fill out the form document. In 
the described embodiment, this shippable code, referred to as a profile, is in the form of a 
JavaScript program. This shippable code is formed from information in the privacy bank 
memory that will enable the form document to be filled out automatically at a step later 
in the process. At step 422 the browser receives the shippable code, or profile, from the 

30 privacy bank server, and now has access to it on the user computer, if desired by the user. 
This profile is stored in the browser residing on the user's computer, and is executable 
upon a user trigger. 

Assuming the user wants to have the electronic form automatically filled out 
using privacy bank, he or she executes a user trigger. In the described embodiment, this 
35 trigger occurs when the user clicks on an "autofill" button contained in the form and 
associated with privacy bank at step 424. By clicking on the autofill button, the user 
allows the browser to execute the shippable code or profile stored thereon. At step 426, 
the shippable code determines whether it contains user data which would permit it to fill 
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out the form dociunent. If user data is contained within the shippable code residing on 
the browser, control goes to step 434 where the browser utilizes the shippable code and 
user data to fill out the electronic form document. Of course, user data being present in 
the shippable code is dependent upon the browser having a pre-existing valid cookie 
5 when the form document was initially retrieved, as described above. 

If, however, user data is not contained within the shippable code residing on the 
browser, control goes to step 428 where the login sequence is initiated in order to identify 
the presently unknown user. The shippable code utilized by the browser in this step 
contains the login sequence code, which is a result of the browser not having a 

10 pre-existing valid cookie when the form document was initially retrieved, as described 
above. The login process of step 428 is described in greater detail in portions of FIG. 5. 
Once the user completes the login sequence at step 428, the privacy bank server assigns a 
cookie to the user/browser thereby enabling it to recognize the user and messages from 
the user's browser in subsequent transactions. At step 430, the privacy bank server 

1 5 retrieves the user data for the identified user, couples this user data and an identifier, such 
as a URL (uniform resource locator), to determine how the electronic form document 
should be filled, and forms a completed package of shippable code containing the user 
data that will be used to fill out the form document. This step is substantially similar to 
steps 418 and 420, as described above. At step 428, the browser receives the shippable 

20 code, or profile, from the privacy bank server, and now has access to it on the user 
computer. This shippable code now contains user data that allows the form document to 
be filled out automatically. At this stage, control proceeds to step 434, where the 
browser utilizes the shippable code and user data to fill out the electronic form document. 
Further input from the user, such as re-clicking on the "autofill" button, is not required. 

25 In other words, once the user properly completes the login sequence, the form is then 
filled out automatically, and it is not necessary for the user to click on the "autofill" 
button again. 

At step 436, the user visually examines the filled out form and the privacy 
features offered by the Web site and decides whether the form is acceptable. If the user 

30 finds that the form needs further adjustment, the user adjusts the document at step 438. 
This may be done manually, or through any supplemental automated process, such as a 
client-based macro. This c£m involve filling in fields that could not be filled in by the 
profile sent by the privacy bank server (in other words, fields that could not be filled out 
from the raw data). Such fields can include, for example, which items being purchased 

35 and the quantity of items. It can also include updated personal information such as a new 
address or credit card number. In this case, the user simply types over the information 
already in the fields. Control then returns to step 436, which is satisfied presumably after 
going through step 438 once. At step 440 the browser submits the filled out electronic 
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form eventually sending it to the merchant's Web server once the user clicks on a Submit 
form button in the browser window.. In the described embodiment, the filled out form is 
first sent to the privacy bank server unbeknovmst to the user or at least transparent to the 
user. The completed form is received and examined by the privacy bank server which 
5 updates its raw data repository to reflect any changes the user may have made to his or 
her personal information. The privacy bank server then posts a message back to the user 
computer (according to HTTP protocol the server must send a message back to the user 
computer when it receives an HTML document from it). In the described embodiment, 
the message it sends back or posts to the user's browser is similar to a "Click Here To - 

10 Continue" type screen to the user. Hidden behind this message is the completed form 
that was sent to the privacy bank server. Presumably, the xiser will click to continue and 
by doing so transmits the hidden completed form to the merchant's Web server. In other 
preferred embodiments, the completed form is sent to both the privacy bank server and 
the merchant's Web server at the same time. In yet another preferred embodiment, the 

15 completed form is posted automatically from the privacy bank server directly to the 
merchant's site without any additional input from the user. At this stage the automatic 
form filling process is complete, 

FIG. 5 is a flow diagram of a process for entering new users into the privacy bank 
service or logging in existing members thereby allowing them to use the service in 

20 accordance with one embodiment of the present invention. Portions of FIG. 5 show in 
greater detail step 428 of FIG. 4 where the login sequence is initiated to identify the user. 
Once the privacy bank server determines that the user does not have a valid cookie, the 
server inserts a login process for the user into the shippable code, whereby an account 
may be created if the user does not already have one. This is done because it is assumed 

25 that if the user has not yet been assigned a cookie from privacy bank for the user's current 
session, he or she has not yet logged onto the privacy bank service or is possibly not a 
registered member. The first event that occurs in the login sequence is the privacy bank 
server displaying a login screen in the user's browser window, as depicted in step 502. 
At step 504 the user decides whether or not he or she is a privacy bank member, and 

30 proceeds to utilize the appropriate section of the login screen. One section of the login 
screen requires the user to input a user identification and password for an existing 
account, while another section permits the user to select an icon that routes the session to 
an account creation screen. 

For account creation, in the described embodiment, the user selects a "New 

35 Account" icon on the login screen, as depicted in step 506. At step 508, a privacy bank 
account creation screen is then displayed. At step 510, the user enters his or her user 
identification, a password, name, other information, and high-level privacy preferences 
into the account creation screen. Essentially the user is configuring the account and 
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personal information items that will be stored for him or her in the privacy bank 
repository. The information inputted into this newly created account is then posted back 
to the privacy bank server, as depicted in step 512. At step 514, the privacy bank server 
accepts the new account information and establishes a location for the new user in the 
5 privacy bank repository. The newly inputted information is then recorded in this 
repository location. The privacy bank server then sets a cookie for the current user 
session, as depicted in step 522, and the process ends. 

For existing user login, in the described embodiment, the user enters his or her 
existing user identification and password, as depicted in step 516. At step 518, this login 

10 information is posted back to the privacy bank server, which then proceeds to evaluate 
the information. At step 520, the privacy bank server determines whether or not the 
posted information is correct, that is, whether or not it corresponds to a valid user 
identification with the proper password. If the posted information does not correspond to 
a valid user identification and password, then the attempted login fails, and the process 

15 reverts to step 502, where a new login screen is displayed. If the posted information is 
correct, then the login is successful, and the process proceeds to step 522. The privacy 
bank server then sets a cookie for the current user session, as depicted in step 522, and 
the process ends. 

FIG. 6 is a flow diagram of a process for deriving the parts needed in constructing 

20 a shippable code segment or profile to be posted to the user in accordance with one 
embodiment of the present invention. It describes a process leading up to step 416 of 
FIG. 4 in which the browser retrieves the shippable code posted from privacy bank in 
greater detail. Recall that the user's browser parses the electronic form to identify and 
then execute any links to external resources to obtain external components to the core 

25 HTML document. In the case of the privacy bank server (assuming the merchant Web 
site from which the electronic form is being downloaded is an affiliate member of 
privacy bank), the server receives and begins to perform operations pursuant to the link 
from the user. At step 602 the user retrieves two items: the user cookie and the identifier 
of the electronic form the user presumably wants to fill out. The user cookie (assigned to 

30 the user by the privacy bank server from when the user logged onto the service) informs 
the privacy bank server of the identity of the user. The identifier of the electronic form 
contains an identifier of the merchant's Web site, and the specific form on the site that 
has been downloaded by the user, also in the form of a URL in the described 
embodiment. In many instances there may only be one form on the Web site. 

35 At step 604 the privacy bank server uses the user cookie to retrieve the user's raw 

data from the privacy bank memory. The configuration and content of the raw data is 
described in greater detail in FIGS. 8A, 8B, and 8C below. The raw data is a set of data 
items very likely needed to fill out common electronic purchasing forms. As is described 
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in greater detail below, each raw data item corresponds to a particular privacy bank 
standard label or name. At step 606 the privacy bank server uses the URL or other 
identifier for the specific form to be filled out to retrieve a mapping of each field name in 
the electronic forms (i.e. the legacy names) to privacy bank standardized names. This 
5 mapping or field name matching is performed when a merchant becomes an affiliate 
member of the privacy bank service. At that juncture the merchant submits one or more 
forms to privacy bank which then examines each field name in the forms and matches it 
with a privacy bank field name. In the described embodiment, if there is a legacy name 
that does not have a matching privacy bank field name, the privacy bank user raw data 

1 0 configuration can be updated if it is believed that the particular legacy field name may 
begin appearing on other forms. Otherwise, it is left for the user to manually fill in as 
described in step 424 of FIG. 4. 

At step 608 the server merges the retrieved name map and the user's raw data 
through a join type operation. The merger between two tuples: the legacy name/privacy 

1 5 bank name tuple and the privacy bank name/raw data value tuple is described in greater 
detail below. The outcome of this merger is a series of tuples matching a legacy name 
with a raw data value associated with the user. In other preferred embodiments this 
merger can be performed using other data constructs and operations. However, the 
outcome is a pairing of a legacy field name and a raw data value. At step 610 the series 

20 of tuples fi-om the merger is converted to a shippable code. In the described embodiment 
the shippable code is in the form of a JavaScript program which is posted to the browser 
on the user computer. Normally, browser programs have a JavaScript component that is 
manipulable by JavaScript commands. These JavaScript commands in the shippable 
code are used to fill in the electronic form on the browser, a technique well known in the 

25 field of Internet and Java programming. It useful to note here that the form is actually 
filled in at the user computer via the browser using the JavaScript commands in the 
shippable code. The form is not filled out on the privacy bank server; the information for 
filling out the form is constructed there but is then posted to the user computer. At this 
stage the process of deriving the shippable code on the privacy bank server is complete, 

30 FIG. 7 is a flow diagram of a process for mapping through which form names are 

mapped to a user's raw data values in accordance with one embodiment of the present 
invention. As described above, at step 702 the privacy bank server uses the form URL or 
other identifier to retrieve a mapping for the form that maps a legacy name with a privacy 
bank standardized name. The mapping also contains one or more practices for each field 

35 name, described in greater detail below. This mapping is created when a merchant or 
service provider decides to become an affiliate member of the privacy bank service. 
During the registration process the merchant tells privacy bank which forms it wants to 
register and the field names in those forms, which are then paired with privacy bank 
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Standardized names. At step 704 the user cookie is used to obtain the user's raw data, 
which includes actual data values and preferences associated with each data value. The 
practices mentioned above associated with legacy names and the preferences associated 
with user raw data values are stated in terms of conditions. In the described embodiment, 
5 there are various conditions, such as marketing (targeted), system administration, 
personalization, research and development, and completion of activity (i.e. ordering). 
Other embodiments can more or fewer conditions. 

When a merchant registers wdth the privacy bank service, it must state what 
conditions for which it will use each legacy field. For example, for the field "Last Name" 

10 it may state that its practice will be to use this field for "personalization" and "completion 
of activity," and nothing else. For a "Method of Payment" field, it may state that its 
practice will be to use this field for "completion of activity," "research and development," 
and "administration" only. In this manner, the merchant will build a list of (legacy field 
name, practice) pairs stored in the privacy bank server. Similarly, when a user becomes a 

1 5 member of the privacy bank service, he or she is required to provide the raw data values 
(specific fields for the raw data are described below) and corresponding preferences, also 
stated in terms of conditions. They are called preferences because from the user's point 
of view they indicate a privacy or use threshold. For example, a user can require that her 
last name can only be used for "personalization," "completion of activity," and "system 

20 administration," thereby excluding its use for targeted "marketing" for example. In the 
described embodiment, if a user does not specify a preference condition, the data item is 
not to be released, such as a social security number or a mother's maiden name. 

At step 706 the privacy bank server retrieves a single (legacy name, practice) pair 
and its corresponding standardized privacy bank name firom the form mapping retrieved 

25 at step 702. In the described embodiment, this pair can be the first form field in the 
merchant's online form. At step 708 the server retrieves a corresponding (standardized 
privacy bank name, preference) pair from the user's raw data "file." The privacy bank 
name in this pair should match the privacy bank name in the pair retrieved at step 706: 
[(legacy name, practice), PB NamelJ: fPB Name J, preference] 

30 At step 710 the privacy bank server compares the merchant's practice conditions 

on the left with the user's preference conditions on the right. For example, for the last 
name field, the merchant has specified that its practice is to use this data item for the 
conditions "personalization" and "completion of activity.'* The user has specified she 
will only allow her last came to be used for the conditions "personalization," "completion 

35 of activity," and ''system administration." The merchant's conditions and the user's 
conditions are compared. At step 712 the privacy bank server determines whether the 
merchant's form field should be filled in taking into account the user's privacy threshold 
for that field. In the described embodiment this is done by determining whether the 
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user's preference conditions is a superset of the merchant's practice conditions. That is, 
does the merchant intend to use the user's last name for anything other than what the user 
has specified. In the last name example, the user's preferences is a superset of the 
merchant's practices: "personalization," "completion of activity," and "system 
5 administration" includes at least all of "personalization" and "completion of activity." 

If the user's preferences are not a superset of the merchant's practices, control 
goes to step 714 where a message is displayed to the user indicating that the field will not 
be automatically filled in because the merchant may use that information in ways the user 
has not authorized. In the described embodiment, if one field in the form meets this 

10 condition, none of the fields in the form are filled in and the process is complete. In 
other preferred embodiments, the user has the option to fill in the field manually and 
have the privacy bank service proceed with the remaining fields. 

If the user's preferences are a superset of the merchant's practices, control goes to 
step 716 where the field is filled in with the raw data value. Steps 710 and 712 can be 

1 5 seen as a two-step negotiation process. The merchant form, seen as an "information 
buyer," makes a proposal to the user, the "information seller." The proposal is essentially 
in the form of what data item the information buyer wants and what he intends to use it 
for. This is the first step in the negotiation process where the privacy bank server acts as 
a negotiator. The user gets the proposal and checks whether the merchant's conditions 

20 exceed what the user's preferences. In other words, the user checks whether the merchant 
intends to use the data item for pxuposes not specifically allowed by the user. If the 
merchant's practice conditions are acceptable (by performing the superset test in 
step 712), the user sends an acceptance to the merchant, at which point the raw data value 
is retrieved and associated with the legacy field. If the merchant's conditions are not 

25 acceptable, the user essentially sends a "not accepted" message to the merchant through 
the negotiator without a raw data value. This completes the second step in the 
negotiation process. Each two-step negotiation is viewed as an object which is later used 
to construct a JavaScript program (the shippable code) using standard Java programming 
techniques. 

30 At step 718 the server checks whether there are any other (legacy name, practice) 

pairs in the merchant's form. If there are more legacy fields, control returns to step 706 
and the process repeats. If there are no more fields to be filled in, the process is 
complete. At this stage there is a series of objects or a history of negotiations that has 
been derived from the mapping process. These series of objects are then used to 

35 construct a JavaScript program. In the described embodiment, all the objects will have 
an acceptance from the user and thus a raw data value attached which is included in the 
JavaScript profile sent over to the 'browser/user. In other preferred embodiments, some 
of the objects can have a "not accepted" or declined message indicating that a particular 
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field in the form will not be filled in and thus will not have a raw data value. As 
mentioned above, in the described embodiment if one of the fields in the form cannot be 
filled in because the merchant's practices exceed the user's preferences, the entire form is 
not filled in. The shippable code or profile sent to the user represents a series of (legacy 
5 field name, raw data value) pairs without any reference to preferences or practices, all the 
negotiations for the data values having been performed on the privacy bank server. 

FIG. 8 is a high-level table diagram showing how fields containing the raw data 
and preferences for a user are organized on the privacy bank server in accordance with 
one embodiment of the present invention. A top-level User table 802 has four columns: 

10 User 804, Category 806, Type 808, and Short display name 810. User Table 802 has 
four areas of data under colimm User 804 represented by four rows: Home 812, 
Work 814, Billing 816, and Shipping 818, In the described embodiment, the user is 
presented with these four areas of data when registering with the privacy bank service 
and enters information by going through each of these data areas. Skipping Category 806 

1 5 for the moment, column Type 808 takes the raw data tree down one level from the top 
level represented by table 802. For example, the Type for data area Home 812 is Info. 
This performs as a pointer or link to an Info table 820. The first column 822 of table 820 
is labeled Info but the other three columns are the same as shown in table 802^ that is, 
Category 806, Type 808, and Short display name 810. 

20 At table 820, the user begins entering data that will be used for her home 

information and for Shipping since data area 818 for Shipping in table 802 also has an 
Info in its Type column 808. A Name row 822 has in its Type column 808 a reference to 
yet another table PersonName, shown as table 824. Similar to table 802 and 820, 
PersonName table 824 has a first column labeled PersonName and the same three 

25 columns as the other tables. All five data areas in PersonName table 824: Prefix, First, 
Middle, Last, and Suffix have as a Type a primitive type referred to as Text in the 
described embodiment. Text represents a data string that is the actual data item stored in 
the privacy bank server. By examining the Type colunrm 808 of each of the data areas, a 
user enters all the raw personal data. An actual data item is entered at each Type box 

30 containing Text, indicating a primitive type, or a leaf node when viewed as a tree 
structure. If the Type column does not contain "Text," another table exists that refines 
the data area further. 

To follow another example, under the data area Billing 816 shown in table 802, 
its Type 808 indicates Billlnfo and not Text. A table Billlnfo has six further data areas, 
35 none of which have a Text Type, so no actual data values can be found at this level. 
Taking the CreditCard data area as an example, its Type indicates "CreditCard." Table 
CreditCard, shown in FIG. 8C, has four data areas: Type, Number, ExpMonth, and 
Exp Year, all of which are of Type Text, which contain actual data values. 
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Short display name column 810 contains a string that is displayed to the user 
through a user registration graphical user interface of the described embodiment. The 
user follows the data tree via a user interface using the Short display name strings as field 
names or guides to entering the data. The data areas that have primitive Types, which in 
5 the described embodiment is Text, are the privacy bank field names that are mapped with 
the legacy field names in the electronic forms registered v^th the service. In the 
described embodiment, the privacy bank names include (in abbreviated form): 



PersonName.Prefix 
1 0 PersonName.First 
PersonName.Last 
PersonName. Suffix 

15 

Intemet.Email 
Intemet.HomePage 

CreditCard.Type 
20 CreditCard.Number 
CreditCard.ExpMonth 
CreditCard.ExpYear 

Category column 806 is related to privacy settings set by the user and are tied to 
the preferences set by a user and defined in terms of the conditions as described above, 

25 specifically in FIG. 7. The conditions or use thresholds in the described embodiment are 
marketing (targeted), system administration, personalization, research and development, 
and completion of activity (i.e. ordering). The Categories available in the described 
embodiment and as shov^ in the tables of FIGS. 8A, SB, and 8C, are Physical Contact 
Information, Online Contact Information, Demographic Data, and Financial Data. The 

30 relationship between the Categories and the conditions of the described embodiment can 
be described as a table five-row, four-column table (a 20 cell table) where each condition 
is one row in the table and each Category is one column in the table. 

The present invention employs various computer-implemented operations 
involving data stored in computer systems. These operations include, but are not limited 

35 to, those requiring physical manipulation of physical quantities. Usually, though not 
necessarily, these quantities take the form of electrical or magnetic signals capable of 
being stored, transferred, combined, compared, and otherwise manipulated. The 
operations described herein that form part of the invention are useful machine operations. 



Address.Streetl 
Address.Street2 

Address.City PhoneNum.AreaCode 

Address.StateProv PhoneNum.Number 

Address.PostalCode PhoneNum.Extension 
Address.Country 

Employment.Employer 

Employment.Department 

Employment.JobTitle 
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The manipulations performed are often referred to in terms, such as, producing, 
identifying, running, determining, comparing, executing, downloading, or detecting. It is 
sometimes convenient, principally for reasons of common usage, to refer to these 
electrical or magnetic signals as bits, values, elements, variables, characters, data, or the 
5 like. It should remembered, however, that all of these and similar terms are to be 
associated with the appropriate physical quantities and are merely convenient labels 
applied to these quantities. 

The present invention also relates to a device, system or apparatus for performing 
the aforementioned operations. The system may be specially constructed for the required 

10 purposes, or it may be a general purpose computer selectively activated or configured by 
a computer program stored in the computer. The processes presented above are not 
inherently related to any particular computer or other computing apparatus. In particular, 
various general purpose computers may be used with programs vmtten in accordance 
with the teachings herein, or, alternatively, it may be more convenient to construct a 

1 5 more specialized computer system to perform the required operations. 

FIG. 9 is a block diagram of a general purpose computer system 900 suitable for 
carrying out the processing in accordance with one embodiment of the present invention. 
FIG. 9 illustrates one embodiment of a general purpose computer system such as user 
computer 302 of FIG. 3 A and also describes many components found in privacy bank 

20 server 308. Other computer system architectures and configurations can be used for 
carrying out the processing of the present invention. Computer system 900, made up of 
various subsystems described below, includes at least one microprocessor subsystem 
(also referred to as a central processing unit, or CPU) 902. That is, CPU 902 can be 
implemented by a single-chip processor or by multiple processors. CPU 902 is a general 

25 purpose digital processor which controls the operation of the computer system 900. 
Using instructions retrieved from memory, the CPU 902 controls the reception and 
manipulation of input data, and the output and display of data on output devices. 

CPU 902 is coupled bi-directionally with a first primary storage 904, typically a 
random access memory (RAM), and uni-directionally with a second primary storage area 

30 906, typically a read-only memory (ROM), via a memory bus 908. As is well known in 
the art, primary storage 904 can be used as a general storage area and as scratch-pad 
memory, and can also he used to store input data and processed data. It can also store 
programming instructions and data, in the form of data objects or JavaScript programs, 
for example, in addition to other data and instructions for processes operating on 

35 CPU 902, and is used typically used for fast transfer of data and instructions in a 
bi-directional manner over the memory bus 908. Also as well known in the art, primary 
storage 906 typically includes basic operating instructions, program code, data and 
objects used by the CPU 902 to perform its functions. Primary storage devices 904 and 
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906 may include any suitable computer-readable storage media, described below, 
depending on whether, for example, data access needs to be bi-directional or 
uni-directional. CPU 902 can also directly and very rapidly retrieve and store frequently 
needed data in a cache memory 910. 
5 A removable mass storage device 912 provides additional data storage capacity 

for the computer system 900, and is coupled either bi-directionally or uni-directionally to 
CPU 902 via a peripheral bus 914. For example, a specific removable mass storage 
device commonly known as a CD-ROM typically passes data uni-directionally to the 
CPU 902, whereas a floppy disk can pass data bi-directionally to the CPU 902. 

10 Storage 912 may also include computer-readable media such as magnetic tape, flash 
memory, signals embodied on a carrier wave, PC-CARDS, portable mass storage 
devices, holographic storage devices, and other storage devices. A fixed mass storage 
916 also provides additional data storage capacity and is coupled bi-directionally to CPU 
902 via peripheral bus 914. The most common example of mass storage 916 is a hard 

1 5 disk drive. Generally, access to these media is slower than access to primary storages 
904 and 906. 

Mass storage 912 and 916 generally store additional programming instructions, 
data, and the like that typically are not in active use by the CPU 902. It will be 
appreciated that the information retained within mass storage 912 and 916 may be 
20 incorporated, if needed, in standard fashion as part of primary storage 904 (e.g. RAM) as 
virtual memory. 

In addition to providing CPU 902 access to storage subsystems, the peripheral 
bus 914 is used to provide access other subsystems and devices as well. In the described 
embodiment, these include a display monitor 918 and adapter 920, a printer device 922, a 

25 network interface 924, an auxiliary input/output device interface 926, a sound card 928 
and speakers 930, and other subsystems as needed. 

The network interface 924 allows CPU 902 to be coupled to another computer, 
computer network, or telecommunications network using a network connection as 
shown. Through the network interface 924, it is contemplated that the CPU 902 might 

30 receive information, e.g., data objects or program instructions, from another network, or 
might output information to another network in the course of performing the 
above-described method steps. Information, often represented as a sequence of 
instructions to be executed on a CPU, may be received from and outputted to another 
network, for example, in the form of a computer data signal embodied in a carrier wave. 

35 An interface card or similar device and appropriate software implemented by CPU 902 
can be used to connect the computer system 900 to an external network and transfer data 
according to standard protocols. That is, method embodiments of the present invention 
may execute solely upon CPU 902, or may be performed across a network such as the 
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Intemet, intranet networks; or local area networks, in conjunction with a remote CPU that 
shares a portion of the processing. Additional mass storage devices (not shown) may 
also be connected to CPU 902 through network interface 924. 

Auxiliary I/O device interface 926 represents general and customized interfaces 
5 that allow the CPU 902 to send and, more typically, receive data from other devices such 
as microphones, touch-sensitive displays, transducer card readers, tape readers, voice or 
handvmting recognizers, biometrics readers, cameras, portable mass storage devices, and 
other computers. 

Also coupled to the CPU 902 is a keyboard controller 932 via a local bus 934 for 

10 receiving input from a keyboard 936 or a pointer device 938, and sending decoded 
symbols from the keyboard 936 or pointer device 938 to the CPU 902. The pointer 
device may be a mouse, stylus, track ball, or tablet, and is useful for interacting with a 
graphical user interface. 

In addition, embodiments of the present invention further relate to computer 

15 storage products v^th a computer readable medium that contain program code for 
performing various computer-implemented operations. The computer-readable medium 
is any data storage device that can store data which can thereafter be read by a computer 
system. The media and program code may be those specially designed and constructed 
for the purposes of the present invention, or they may be of the kind well known to those 

20 of ordinary skill in the computer software arts. Examples of computer-readable media 
include, but are not limited to, all the media mentioned above: magnetic media such as 
hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; 
magneto-optical media such as floptical disks; and specialty configured hardware devices 
such as application-specific integrated circuits (ASICs), programmable logic devices 

25 (PLDs), and ROM and RAM devices. The computer-readable medium can also be 
distributed as a data signal embodied in a carrier wave over a network of coupled 
computer systems so that the computer-readable code is stored and executed in a 
distributed fashion. Examples of program code include both machine code, as produced, 
for example, by a compiler, or files containing higher level code that may be executed 

30 using an interpreter. 

It will be appreciated by those skilled in the art that the above described hardware 
and software elements are of standard design and construction. Other computer systems 
suitable for use with the invention may include additional or fewer subsystems. In 
addition, memory bus 908, peripheral bus 914, and local bus 934 are illustrative of any 

35 interconnection scheme serving to link the subsystems. For example, a local bus could 
be used to connect the CPU to fixed mass storage 916 and display adapter 120. The 
computer system shown in FIG. 9 is but an example of a computer system suitable for 
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use with the invention. Other computer architectures having different configurations of 
subsystems may also be utihzed. 

Although the foregoing invention has been described in some detail for purposes 
of clarity of understanding, it will be apparent that certain changes and modifications 
may be practiced within the scope of the appended claims. Furthermore, it should be 
noted that there are alternative ways of implementing both the process and apparatus of 
the present invention. For example, the raw data can contain more or few fields than 
those described as needed, and there can be additional privacy or use threshold 
conditions than the five described. In another example, the filled out electronic form can 
be sent automatically to the merchant's Web server after the privacy bank server updates 
its raw data without additional input fi-om the user. In another example, the raw data and 
legacy fields can be bundled and coded in a software module other than as a JavaScript 
module. Accordingly, the present embodiments are to be considered as illustrative and 
not restrictive, and the invention is not to be limited to the details given herein, but may 
be modified within the scope and equivalents of the appended claims. 
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Claims 

What is claimed is: 

1. A method of automatically filling in an electronic form on a user 
computer having a program capable of performing as a browser, the method comprising: 

accessing the electronic form using the program, the program resident on the user 
computer; 

executing a link to a personal information server from the user computer; 

transmitting a personal information module from the personal information server 
to the user computer; and 

executing the personal information module at the user computer to fill in at least 
some of the plurality of fields in the electronic form. 

2. A method as recited in claim 1 wherein accessing the electronic form 
further comprises downloading the electronic form from a remote Web server, the remote 
Web server having registered the electronic form wdth the personal information server. 

3. A method as recited in claim 1 wherein accessing the electronic form 
further comprises displaying the electronic form in a window in the program. 

4. A method as recited in claim 1 wherein executing a link to a personal 
information server further comprises parsing the electronic form upon downloading the 
electronic form onto the user computer. 

5. A method as recited in claim 4 wherein the link is executed upon parsing 
the electronic form to identify the link. 

6. A method as recited in claim 1 wherein executing a link to a personal 
information server further comprises transmitting a session identifier and an electronic 
form identifier to the personal information server, the session identifier associated with 
the user computer. 

7. A method as recited in claim 6 wherein the session identifier is a cookie 
and the electronic form identifier is a Uniform Resource Locator indicating the location 
of the electronic form. 

8. A method as recited in claim 1 wherein transmitting a personal 
information module further comprises examining a plurality of negotiation history 
modules derived for the electronic form and a particular user. 



SUBSTITUTE SHEET (RULE 26) 



wo 00/42540 



-27- 



PCT/USOO/01031 



9. A method as recited in claim 8 wherein each negotiation history module is 
derived utilizing a form mapping corresponding to the electronic form and a raw data 
profile corresponding to the particular user. 

10. A method as recited in claim 8 further comprising constructing a 
JavaScript program from the plurality of negotiation history modules. 

11. A method as recited in claim 1 wherein executing the personal 
information module at the user computer further comprises inserting data strings into the 
plurality of fields in the electronic form. 

12. A method as recited in claim 1 wherein executing the personal 
information module at the user computer further comprises inputting the personal 
information module into a Java-related component of the program. 

13. A method as recited in claim 1 further comprising transmitting the 
electronic form with at least some of the plurality of fields filled in to the personal 
information server. 

14. A method as recited in claim 13 further comprising updating data strings 
on the personal information server upon receiving the electronic form. 

15. A method as recited in claim 2 further comprising transmitting the 
electronic form with at least some of the plurality of fields filled in to the remote Web 
server. 

16. A method as recited in claim 2 wherein the remote Web server, the user 
computer, and the personal information server are all connected through the Internet. 

17. A method as recited in claim 1 wherein the program is a Web browser and 
the electronic form is a form used for purchasing goods or services online. 

18. A method as recited in claim 1 1 further comprising retrieving one or more 
data strings on the personal information server using the session identifier. 

19. A system for automatically filling in an electronic form, the system 
comprising: 

an information server having access to personal information associated with a 
plurality of registered users and a plurality of form mappings; 
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a Web server having access to an electronic form containing an input button 
associated with the information server, wherein the electronic form is registered with the 
information server; and 

a user computer containing a browser and having a user, wherein the electronic 
form is downloaded into the browser and the user is registered with the information 
server; 

wherein the information server and the user computer are in communication over 
a network, such that when the electronic form is downloaded and the input button is 
activated, the electronic form is at least partially filled in while in the browser on the user 
computer. 

20. A system as recited in claim 19 wherein the information server further 
comprises a negotiation history module including a plurality of negotiation objects. 

21. A system as recited in claim 20 wherein each of the negotiation objects 
contains one of an acceptance component and a decline component. 

22. A system as recited in claim 19 wherein the information server further 
comprises a shippable code module constructor for creating a software module 
containing instructions and data strings necessary for the browser on the user computer to 
fill in the electronic form. 

23. A system as recited in claim 22 wherein the software module is a 
JavaScript program. 

24. A system as recited in claim 19 wherein the browser on the user computer 
contains a document parsing component for identifying and executing external links to 
one or more remote electronic resources. 

25. A system as recited in claim 19 wherein the information server ftirther 
comprises a plurality of raw data profiles and a plurality of form mappings. 

26. A system as recited in claim 25 wherein each raw data profile contains 
field names and corresponding data strings. 

27. A system as recited in claim 25 wherein each form mapping contains 
relationships between a first set of fields and a second set of fields. ' 

28. A system as recited in claim 19 wherein the network is the Internet. 
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29. A computer program product for automatically filling in an electronic 
form on a user computer having a program capable of performing as a browser, 
comprising: 

a computer code that accesses the electronic form using the program, the program 
resident on the user computer; 

a computer code that executes a link to a personal information server from the 
user computer; 

a computer code that transmits a personal information module from the personal 
information server to the user computer; 

a computer code that executes the personal information module at the user 
computer to fill in at least some of the plurality of fields in the electronic form; and 

a computer-readable medium that stores the computer codes. 
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